In many computing systems, low-level instruction code is used as an intermediary between the hardware components of the computing system and the operating software and other high-level software executing on the computing system. In some computer systems, this low-level instruction code is known as the Basic Input and Output System (“BIOS”). The BIOS provides a set of software routines that allow high-level software to interact with the hardware components of the computing system using standard calls.
Because of limitations of the BIOS in many PC-compatible computers, a new firmware architecture for booting the computer and for intermediating the communication between the operating system and the hardware has been created. The new architecture is defined via a set of specifications. One of the specifications is called the Extensible Firmware Interface (“EFI”) Specification and is available from INTEL CORPORATION. The original EFI Specification from INTEL CORPORATION is also being extended by the Unified Extensible Firmware Interface Forum (“UEFI”).
The EFI Specification describes an interface between the operating system and the system firmware. In particular, the Specification defines the interface that platform firmware must implement and the interface that the operating system may use in booting. How the firmware implements the interface is left up to the manufacturer of the firmware. The EFI Specification provides mechanisms for EFI drivers to communicate with each other, and the EFI core provides functions such as allocation of memory, creating events, setting the clock, and many others. This is accomplished through a formal and complete abstract specification of the software-visible interface presented to the operating system by the platform and the firmware.
Additional details regarding the EFI and UEFI firmware architecture are defined by the group of specifications called INTEL Platform Innovation Framework for EFI (“the Framework”), which are available from INTEL CORPORATION. Unlike the EFI Specification, which focuses only on programmatic interfaces for the interactions between the operating system and system firmware, the Framework defines programmatic interfaces for performing the full range of operations that are required to initialize the platform from power on through transfer of control to the operating system.
The Framework defines two major execution phases: Pre-EFI Initialization (“PEI”) and the Driver Execution Environment (“DXE”). The PEI phase includes the minimum amount of program code needed to perform basic platform initialization and is executed from non-volatile memory. When the PEI phase has completed its initialization, including the initialization of main memory, control passes to the DXE phase, which performs higher-level platform initialization and diagnostic functions.
The DXE phase is controlled by core code called the DXE foundation. The DXE foundation is a boot service image that is responsible for producing EFI boot services, EFI runtime services, and DXE services. The DXE foundation includes a DXE dispatcher that discovers DXE drivers stored in firmware volumes and executes them in the proper order. The DXE drivers are the components that actually initialize the platform and provide the services required to boot an EFI-compliant operation system or a set of EFI-compliant system utilities. The DXE drivers can also expose services, called protocols, which can be utilized by other DXE drivers.
In order to permit the discovery and utilization of protocols provided by DXE drivers, the DXE foundation maintains a device handle database that contains data regarding the installed protocols and the hardware devices with which they are associated. Other DXE drivers can utilize EFI boot services to look up the available protocols provided by other DXE drivers in the handle database. While the Framework indicates that the DXE foundation should maintain a handle database for storing data identifying the device handles and their installed protocols, the Framework does not, however, define how the device handle database should be implemented.
It is with respect to these considerations and others that the various embodiments of the invention have been made.